Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/dsp/dspgroup/00index.arc/CISDSP.ARC/DSPS17.CIS

Text File | 1988-07-28 | 103.5 KB | 2,790 lines

#: 73502 S17/TAPR NNC/DSP
    06-Apr-88  23:41:41
Sb: #HF Modems, Part 2
Fm: Phil Karn, KA9Q 73210,1526
To: Barry McLarnon VE3JF 71470,3651 (X)

Okay, I concede! It occurred to me after I sent my message and as
I read the remainder of your messages that I was still implicitly
thinking in terms of AWGN channels (I love those acronyms too!) which is
what almost all of the textbooks assume.  Yes, the situation for HF is
very different.

I've never taken a formal course in the subject.  So my knowledge of
coding theory is limited to what I've picked up informally from various
library textbooks.  I wasn't aware of the ability to extend block codes
to handle soft decisions.  If so, great -- that gets rid of the only
real objection I had.  I do think interleaving is something to look at,
since the HF channel is so highly time-varying.  I don't particularly
mind the decoding delays introduced by sequential decoding or by
interleaving, as most HF packet applications are likely to be
non-real-time (e.g., file transfers where you can compensate by just
opening up the flow control windows.) You just pick a time limit.  If
you run out, the decoder just abandons the packet and waits for a
retransmission.

Perhaps we should start by building a good software model of the HF
channel and using it to test our algorithms.  Is this practical? (It
should include some simulated Radio Moscow signals -- but be sure to use
a big enough word size to avoid amplitude overflow.  :-))

Moving up a level, I think we should give some thought to frame
structures (since we are going to support a packet network, right?) If
we're going to use block coding, a bit-oriented framing structure like
HDLC may be difficult to use.  How about a fairly long pseudo-random
sync vector sequence that indicates the start of each frame.  The vector
would be chosen, and the decoder implemented, such that you don't have
to have an exact match, as long as "most" of the bits are recognized.
If the vector is long enough and is chosen to be "different" enough from
the regular codewords, the chances of a false detection should be small.

Phil


#: 73521 S17/TAPR NNC/DSP
    07-Apr-88  14:43:49
Sb: #73502-#HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Phil Karn, KA9Q 73210,1526 (X)

Developing a realistic software model of the HF channel is a toughie... I know
guys who worked on it for years.  Even though there are plenty of guidelines
available on what parameters to use, the models always have shortcomings, like
leaving out impulsive noise and interference.  There's just no substitute for
on-the-air testing, although we do have a black box in our lab where I work
that comes fairly close.  It's a DSP tapped delay line channel simulator in
which the tap weights can be set dynamically according to a measurement of the
time-varying impulse response of an actual channel.  The measurement is done
by transmitting a pseudorandom probe signal over an HF link and recording the
received signal on an instrumentation recorder.  The recorder then can be
played back into the simulator, which analyzes the signal and sets its tap
weights to reproduce the impulse response in the path of the modem signal
under test.  This does a nice job of reproducing the fading and multipath
under repeatable conditions for comparative tests, but it doesn't reproduce
the non-Gaussian noise and QRM.  The nice thing about DSP modems is that we
can try a few different approaches on the air without messing with a bunch of
different hardware.

Re framing structures for HF: we definitely see eye-to-eye on this one.  Dump
HDLC and adopt a robust frame sync strategy?  Right On!  We should have a
selective-repeat ARQ datalink protocol too.  The new framing structure will
allow us to use coding and signal processing to drag those packets out of the
noise.  For more food for thought, dig up the following article:

D. Chase, "Code combining - a maximum-likelihood decoding approach for
combining an arbitrary number of noisy packets", IEEE Trans. Commun., vol.
COM-33, p. 385, May 1985.

I see Franklin also mentioned Chase - he is the guru of soft-decision decoding
of block codes.  Franklin, are you at liberty to disclose some details of the
work you did in this area?

73, Barry


#: 73531 S17/TAPR NNC/DSP
    07-Apr-88  21:21:33
Sb: #73521-#HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

Your question strikes at the heart of the issue i've been struggling with for
the past few months.  An awful lot of the work i've done in this area has been
done for, well i guess i should call it "work".  If work and hobby were less
related, i'd be having a much easier time with these issues. I have to figure
this out for myself.  I would imagine you may have some of the same conflicts?
How do you deal with it?

Re Chase / Golay, etc...  Two years ago, i wrote a chase-algorithm [24,12]
Golay decoder routine.  I did it as part of "work", and as a result, cannot
make it available to the amateur effort.  Seems a shame at one level, but of
course i cannot violate the trust of my co-workers.  Whole reason i gotgot
interested in ham radio again a couple of years ago was to do technical stuff
like this, and now i find it difficult because of its similarity to work.
Sigh.


#: 73699 S17/TAPR NNC/DSP
    11-Apr-88  08:11:52
Sb: #73531-#HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

It is a big problem, and I'm sure Bob and some of the others are wrestling
with it as well.  I guess, as you say, everyone has to work this out for
himself... in other words, apply "situation ethics".  My current situation is
not too bad, as I work for a gov't research lab on unclassified projects, and
much of our work becomes freely available in the open literature.  On the
other hand, we also transfer technology to private industry for commercial
exploitation, so the material transferred becomes proprietary in those
instances.  I'd like to think there is a fine line we can walk, where we can
make use of some of the "intellectual property" we've acquired from the work
side, in the hobby side, without overstepping the bounds by using the details
of actual implementations.  When in doubt, I probably err on the side of the
hobby... :-)


#: 73714 S17/TAPR NNC/DSP
    11-Apr-88  10:04:54
Sb: #73699-HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

You say you've been archiving the DSP section? Paul Williamson, KB5MU, asked
me whether an archive was available, and i didn't know the answer.  Paul was
admitted to the section a few days ago, and wanted to catch up on ancient
history.  Listening Paul?


#: 73600 S17/TAPR NNC/DSP
    09-Apr-88  08:17:27
Sb: #73521-HF Modems, Part 2
Fm: David Toth VE3GYQ 72255,152
To: Barry McLarnon VE3JF 71470,3651 (X)

I have a test model ready to go whenever you guys want. It's called the HF
Packet Network, and we can get ALL the guys to test the code (20+ stations per
freq x 2 frequencies i.e. 14.109 and 10.149) ...

I know it is not as convenient as a simulation, but it is real and can be
controlled.
Just a useless offer <grin>
Dave


#: 74051 S17/TAPR NNC/DSP
    18-Apr-88  16:05:48
Sb: HF Modems, Part 2
Fm: Bob McGwier N4HY 74615,1366
To: Phil Karn, KA9Q 73210,1526

No problem doing soft decision decoding on these,  I do it all the time but I
have the DAMNDEST time remembering what is or isn't transmittable if you catch
the drift.  I will check into it and I am sure that Barry and Franklin will
know about ways to soft decision decode these fellows, then I will know what
the limits are. Bob

#: 73533 S17/TAPR NNC/DSP
    07-Apr-88  21:30:33
Sb: Queries
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565 (X)

I received the promised return phone call from Beth Harwood of Analog Devices
today.  She claims to have checked with engineering re possible effects of
clocking the 7569 at 6.25 MHz.  The answer is that "it won't work" "it will
miss codes" "it will probably work ok at 5.5 MHz". I thanked her for the
return call, but did not inquire further. Her number is:  617-935-5565
X-2628.

On related issue... seems there are new cmos A/D & D/A announcements every
day.  Just saw in ECN announcement from Linear Technology for LTC1092. 10 bit
A/D, with sample & hold.  8-pin dip.  Serial interface (yuk). 20uS conversion
time, $10.15 in 100 quantity.   Good news is it's >8 bits for reasonable price
and small board area.  But, gee... serial interface? I'm not pushing this
chip.. i just saw the blurb & thought i'd pass it on.


#: 73538 S17/TAPR NNC/DSP
    07-Apr-88  23:11:21
Sb: AD7569
Fm: Lyle Johnson, WA7GXD 76246,565
To: Franklin Antonio

Franklin,

Well, I'll plan on letting it self-clock then using its internal oscillator.
The down side is the "jitter" we'll see in conversion times, especially if we
let the end of conversion trigger the D/A load (which we therefore won't!).

I appreciate the information.

I gave Dan and Eric and Chuck the last 150k or so from here and expect some
feedback from them soon.

Onward!

Lyle


#: 73689 S17/TAPR NNC/DSP
    10-Apr-88  23:09:37
Sb: #73561-#Dayton Hotel
Fm: Tom Clark W3IWI 71260,3640
To: Franklin Antonio, N6NKF 76337,1365 (X)

I've been trying to follow the heuristic discussions on the HF schemes
and I'm getting a bit confused in the terminology. My problem is
that I come from a different signal processing world (radio astronomy,
replete with its own jargon pertaining mainly to signals that >>ARE<<
noise, plus SETI).
I have a modest proposal for those of us who have some ideas, but
feel we are saying the same thing with a biorthogonal set of semantics
(perhaps even from a parallel universe!). Bob M, Phil K, Franklin A,
and Tom C will be at Dayton. Barry M >>>SHOULD<<< come (I'll twist
his pointy little head if he doesn't, & I know Dr. Death has offered
him a ride). Therefore, whatsay we plan to get together for a few
hours and discuss the ideas INCLUDING defining each of our own set
of terminology!   ;-)
73, Tom


#: 73742 S17/TAPR NNC/DSP
    12-Apr-88  02:33:03
Sb: #73689-Dayton Hotel
Fm: Phil Karn, KA9Q 73210,1526
To: Tom Clark W3IWI 71260,3640 (X)

Yes! I think a late-nite bull session at Dayton, ideally in Tom Clark's
hotel room, would be a perfect way to get the creative DSP juices
flowing.  Tom can provide the liquid stimulants as he always does.  :-)

Tom -- re TCP/IP demo -- I'll have my NEC laptop, and that also has a
CGA spigot.  A direct SLIP connection between two machines is sufficient
to demonstrate the end-to-end capabilities, which are the important
part.  But the more machines, the merrier.  It'll be fun to try the LCD
projection display, I've been trying to find one of those for some time.

I suspect, but do not actually know, that the Atlanta gang will be
demoing tcp/ip on top of their 56kbps modems.  They did that last year
with a pair of full-blown ATs.

Phil


#: 73750 S17/TAPR NNC/DSP
    12-Apr-88  08:01:41
Sb: #73689-#Dayton Hotel
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640 (X)

Ouch!  Alright, already, I'll come... but I may have to get you to explain to
my wife why this is so important (keeping the Free World safe from bit errors,
etc... ?).  :-)

Barry


#: 73822 S17/TAPR NNC/DSP
    14-Apr-88  08:29:43
Sb: #73750-#Dayton Hotel
Fm: HamNet SysOp Scott W3VS 76703,407
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry,

Have you got a hotel room arranged for Dayton?  If not, you can have mine...
arranged through the TAPR office.  I'm not able to attend this year due to
work commitments.

Scott

1 Reply

#: 73833 S17/TAPR NNC/DSP
    14-Apr-88  13:01:55
Sb: #73822-#Dayton Hotel
Fm: David Toth VE3GYQ 72255,152
To: HamNet SysOp Scott W3VS 76703,407 (X)

Scott, Barry is coming down with me and a few others and has a room with us.
73, Dave


#: 73840 S17/TAPR NNC/DSP
    14-Apr-88  17:30:01
Sb: #73833-Dayton Hotel
Fm: HamNet SysOp Scott W3VS 76703,407
To: David Toth VE3GYQ 72255,152 (X)

OK on Barry having a room.  Anybody want mine?

Scott


#: 73787 S17/TAPR NNC/DSP
    12-Apr-88  23:34:25
Sb: #73689-#Dayton Hotel
Fm: David Toth VE3GYQ 72255,152
To: Tom Clark W3IWI 71260,3640 (X)

Barry IS coming with us.
73, Dave


#: 73850 S17/TAPR NNC/DSP
    14-Apr-88  20:35:00
Sb: #73787-Dayton Hotel
Fm: Tom Clark W3IWI 71260,3640
To: David Toth VE3GYQ 72255,152 (X)

Great -- don't have to send Guido and Sonny north of the border to
do persuasion!


#: 73607 S17/TAPR NNC/DSP
    09-Apr-88  09:44:10
Sb: #TMP320C15
Fm: Lyle Johnson, WA7GXD 76246,565
To: Tom Clark

Tom,

I gave Cris the TMP320C15 processor yesterday.  She should have sent it out,
so you will probably receive it by the middle of next week.  I have no way of
checking to see if it will work at 25 MHz or not, so...

I also note that the old GI (I think they call themselves MicroSemi now) just
announced a 32 MHz version of the 320C10.  If we can get by without the
additional memory of the '15, we can drop our cycle times to 125 nSec rather
than 160 nSec and save a few dollars in the process.

I suspect the memory is more valuable than the speed, but thought I'd mention
it.

Lyle

1 Reply

#: 73690 S17/TAPR NNC/DSP
    10-Apr-88  23:09:51
Sb: #73607-TMP320C15
Fm: Tom Clark W3IWI 71260,3640
To: Lyle Johnson, WA7GXD 76246,565 (X)

Thanks Lyle. I'll look forward to seeing it.
FYI -- for the 'travelling circus' at Dayton I'll be bringing an
XT clone (the old Mitsubishi that ran the IWI BBS for a couple of
years). I have access (from work) to one of the new transmission
LCD devices that allows a CGA screen (in monochrome) to be displayed
with a viewgraf machine. That way the entire audience can really
see the screen (for a change). [Phil -- how do you want to demo NET?
that machine could either be used on a SLIP link or I could drop
an ethernet board into it].


#: 73617 S17/TAPR NNC/DSP
    09-Apr-88  14:09:13
Sb: #HF Modems
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry, i saw some comments go by a while back re peak-to-average power ratio
for sum of sinusoids.  Seem to remember it was a msg from you to Tom C. The
msg must have scrolled off the end of the universe, as i cannot find it now.
Seem to remember that you gave a formula.  Is this in the literature anyplace?
If not, could you repeat the formula?


#: 73700 S17/TAPR NNC/DSP
    11-Apr-88  08:12:25
Sb: #73617-#HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

I'll do better than that... I'll dust off that message and ship you a copy in
its entirety.  I've been archiving all of the DSP discussions here since about
the beginning of February.  It's now up to about 300K of text!

A few more points that I left out of the original posting:

- There is a perfectly good term for peak-to-average ratio which we should
  make use of, namely crest factor (no puns about preventing cavities,
  please!)

- Since we are normally comparing multitone formats to a single tone, which
  itself has a 3 dB crest factor, we should subtract 3 dB from the multitone
  figures to get to get the true relative rating.

- The reference for the data on crest factors of phase-controlled multitone
  signals is: S. Boyd, "Multitone signals with low crest factor", IEEE Trans.
  Circuits Syst., Vol. CAS-33, Oct. 1986, pp. 1018-1022.


#: 73713 S17/TAPR NNC/DSP
    11-Apr-88  10:01:27
Sb: #73700-HF Modems
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

Crest factor?  Never heard of it.  I think i've been computing the Colgate
factor.  I tend to think of signals in the two-dimensional model, and look at
the length of the resulting vector.  When it stays on the unit circle, as it
does with a single tone, then peak=avg, and i call that a peak/avg ratio of
0db.  I'll go look up that paper immediately.


#: 73731 S17/TAPR NNC/DSP
    11-Apr-88  22:01:29
Sb: #73700-#HF Modems
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry -- pull me off a copy of the collected annals of DSPdom too
for inclusion with the distribution disks Bob & I send out.
On the next disks I hope to also have Phil's 'sounds' but I have
to do some archive splitting. He FTPd me one 900kbyte long .ARC
file! But some of the 'sounds' he included are either scatalogical
or X-rated and probably shouldn't be circulated   ;-)


#: 73765 S17/TAPR NNC/DSP
    12-Apr-88  13:06:30
Sb: #73731-HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640 (X)

OK, I'll bring several copies of the DSP Chronicles with me to Dayton for
distribution to the folks on the team.

Barry


#: 73740 S17/TAPR NNC/DSP
    12-Apr-88  01:21:56
Sb: #73700-#HF Modems
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

I picked up a copy of the Boyd article, and the Ouderaa, Schoukens, Renneboog
comments (Sept '87 IEEE-CAS).  Now i see that your definition of "crest
factor" is just 3db greater than my "peak/avg power". This article blew me
away.  The Shapiro-Rudin sequences are amazing. Just don't look like they'll
do the trick, do they?  Nonituitive.

Problem is, i'm not clear on how to apply this to our benefit. They provide
phases which will produce a reasonable crest factor IF YOU WANT ALL THE
EQUALLY SPACED TONES IN SOME BAND.  We want N out of M tones in some band.  So
suppose we have possible tones (evenly spaced) numbered 0, 1, 2, 3, 4, 5, 6,
7, 8.  Now i want only tones 1, 3, 7 turned on.  What are the correct phases
of these three tones for low crest factor?  Can i get the answer out of this
paper?


#: 73766 S17/TAPR NNC/DSP
    12-Apr-88  13:07:29
Sb: #73740-#HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Fascinating, isn't it?  Whether it's useful is quite another matter.  Thanks
for finding that follow-up letter, which I hadn't come across.

I was particularly taken with 32-tone Newman signal, which resembles a swept
tone.  This suggests a different approach to minimizing crest factor, namely,
start with a constant-envelope (or nearly so, at least) signal that has an
approximately flat magnitude spectrum over the bandwidth of interest.  In this
case, it is a chirp (linear FM) signal.  Then do a complex DFT on the signal,
with the sample rate corresponding to the desired tone spacing.  Then we can
use tones to synthesize a signal resembling the constant-envelope signal we
started with by setting the tone amplitudes to be all the same, and using the
phases that we derived from the DFT.

Getting back to your question re whether we can use the results of this paper
to minimize the crest factor for a subset of the tones, I think the answer
clearly is NO.  Anything we do to modulate information onto the ensemble of
tones, whether it be selecting n-of-m, OOK, FSK, PSK, or what have you, will
violate the constraints and cause the crest factor to increase.  In a sense,
we have used up all the available degrees of freedom in order to minimize the
crest factor, and have none left over to transmit information with!

When the tones are not equally spaced, as in the n-of-m or multitone OOK
schemes we've been talking about, I think we would have to resort to a
computer search for the optimum phases of the component tones for EACH
POSSIBLE SYMBOL.  Once found, they can be stored in a lookup table which is
referenced by the DSP modulator.  This seems workable for a 300 bps/50 baud
modem with 64 possible symbols, but gets unwieldy when you think about higher
bit rates (which, of course, is exactly where we need it most).  A colleague
of mine has done some work on using the steepest descent algorithm to minimize
crest factors when the tones are not equally spaced (S. Shlien, "Minimization
of the peak amplitude of a waveform", Signal Processing, Vol.14, No.1, Jan.
1988).


#: 73849 S17/TAPR NNC/DSP
    14-Apr-88  20:34:49
Sb: #73766-#HF Modems
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Re the Newman (Alfred E.?) chirp scheme. It sounds like this is a
group delay encoding trick since group delay = - (d phase)/(d freq)
[oh to have math symbols available!]. Given the dispersive character
of the ionosphere I fear this kind of scheme is frought with peril.
I suspect we'd spend all our computing horsepower (and more) trying
to adaptively equalize delay twiddles from the medium.


#: 73899 S17/TAPR NNC/DSP
    15-Apr-88  13:59:47
Sb: #73849-HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640 (X)

What, me worry?

I wasn't proposing this as a signalling technique... just thought it was
interesting that that particular mathematical trick to minimize crest factor
of a group of sinusoids turned out to synthesize a chirp-like waveform.  Of
course, if we really wanted to use a chirp, it would be easier to use a
dispersive delay line to generate and demodulate it.  Chirp modulation
actually has been used successfully in HF modems as a spread-spectrum
technique for beating multipath, e.g., do an "up-chirp" to send a 1, and a
"down-chirp" to send a 0.  But you need bandwidth >> data rate to get a decent
amount of processing gain out of it, so it is only good for low data rates (<
300 bps) if you are feeding it through an SSB rig.


#: 73701 S17/TAPR NNC/DSP
    11-Apr-88  08:13:21
Sb: #73617-#HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Tom, things aren't quite as bad as they seem, and we should not abandon all
hope of using multitone modems.  Here's why:

Your estimate of the PAR is a little on the high side.  When N equal-amplitude
sinusoids are added together, the PAR of the resulting signal is nominally
equal to 20*log[SQRT(2N)].  For N = 16, this works out to about 15 dB, and for
N = 32, it is about 18 dB (I am ignoring for the moment, the varying number of
simultaneous tones if OOK is used).

Also: up to a point, you can clip the peaks of the waveform (before applying
it to the SSB modulator) without doing any harm.  The limit is reached when
the "self-noise" from intermod products start to have a significant effect on
the bit error rates.  Commercial 16-tone modem systems are typically run at 3
to 5 dB higher average power than that dictated by the PAR.

Here's an interesting footnote:  The reason I referred to the PAR above as
nominal is that it can be reduced if we put some constraints on the sinusoids.
The first constraint is that the tone frequencies be equally spaced, which we
want anyway.  Now if we control the phases of the tones (easy with DSP!), we
can reduce the PAR quite dramatically. The absolute worst choice is to start
them all in phase - then we get no improvement at all.  However, with the
proper choice of just two different phases, 0 and pi, for each tone, the PAR
can be made MUCH lower.  For N = 32, the PAR can be reduced to 6 dB.  And
there is an even better algorithm that requires a different phase shift for
each tone (which can be stored in a look-up table). It results in a PAR of 4.6
dB (!) for N = 32, and the PAR is <6 dB for ALL N. For large N, it produces a
near-constant-envelope signal that bears a striking resemblance to a swept
tone.  The bad news is, if we start phase- or amplitude modulating the tones,
we upset the applecart and the PAR starts heading back up.  Everything is fine
as long as we don't try and transmit any information! :-)

73, Barry


#: 73732 S17/TAPR NNC/DSP
    11-Apr-88  22:01:42
Sb: #73701-HF Modems
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Thanks for the comments Barry. I have been meaning to do a simulation
of multi-tone schemes with different spacings and initial phases.
Franklin's Crest/Colgate comment hilights one of the reasons I think
it would be splendid if we could meet in Dayton for discussons of
orthogonal polynomials and related topics. Can you come?


#: 74007 S17/TAPR NNC/DSP
    17-Apr-88  20:23:07
Sb: HF Modems
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Sounds like a good plan.  Dave sent me a good message bearing great news! Bob


#: 74053 S17/TAPR NNC/DSP
    18-Apr-88  16:06:34
Sb: HF Modems
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

1800 Hz sounds right.   These VBP tuning rigs are nice. Bob

#: 73693 S17/TAPR NNC/DSP
    10-Apr-88  23:10:17
Sb: Meese
Fm: Tom Clark W3IWI 71260,3640
To: N6NKF

Franklin -- tried to run your spectrum code at home where I have a VGA
video (running EGA mode) plus a Mouse Systems serial mouse. The mouse
is installed with the driver that is supposed to make it look like
a Microsoft mouse. It doesn't work. No cursor appears, I can't move
up & down the scroll bar. Pressing the buttons does non-reproducable
things. What am I doing wrong?
73, Tom


#: 73694 S17/TAPR NNC/DSP
    10-Apr-88  23:10:27
Sb: #S17 membership
Fm: Tom Clark W3IWI 71260,3640
To: Scott

I understand that Courtney Duncan, N5BF (now living in Pasadena)
is on CIS. He is one of the DSPers and he told me that he does not
have access to S17. Don't have his account number. Can you add him?
73, Tom

1 Reply

#: 73828 S17/TAPR NNC/DSP
    14-Apr-88  09:09:06
Sb: #73694-#S17 membership
Fm: HamNet SysOp Scott W3VS 76703,407
To: Tom Clark W3IWI 71260,3640 (X)

Tom,

I've added Courtney to the group able to access Section 17.

Scott

1 Reply

#: 73851 S17/TAPR NNC/DSP
    14-Apr-88  20:35:20
Sb: #73828-#S17 membership
Fm: Tom Clark W3IWI 71260,3640
To: HamNet SysOp Scott W3VS 76703,407 (X)

Thanks Scott -- now another one, if you please. Richard (Rick) Hambly,
WB2TNL from Annapolis just joined CIS. He has one of the TAPR/AMSAT
boards, and in a prior incarnation (when working for Harris) did
some work on adaptive HF modems. Rick is now a senior engineer with
AIRINC working on aeronautical digital schemes. Rick is also sysop
of the W3ZH BSS.
Thanks, Tom

1 Reply

#: 73878 S17/TAPR NNC/DSP
    15-Apr-88  08:30:34
Sb: #73851-#S17 membership
Fm: HamNet SysOp Scott W3VS 76703,407
To: Tom Clark W3IWI 71260,3640 (X)

Tom,

I just added Rick Hambly, WB2TNL, to the Section 17 list also.  Any others?

Scott

1 Reply

#: 74011 S17/TAPR NNC/DSP
    17-Apr-88  20:53:18
Sb: #73878-#S17 membership
Fm: Tom Clark W3IWI 71260,3640
To: HamNet SysOp Scott W3VS 76703,407 (X)

Scott -- one more to add: John Connor, WD0FHG from Colo. Spgs.,
# 72165,743. John was one of the original adventurous 10 to get
the 32010 boards and in a fone call today said something like
"Oh -- is there a DSP group on CIS?". Guess I really need to poll
all the original adventurers!


#: 73841 S17/TAPR NNC/DSP
    14-Apr-88  17:30:10
Sb: #Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon 71470,3651 (X)

You make a waveform and push it in the audio input of an SSB rig, then it
gets frequency shifted to HF, and goes to a power amplifer.  We are concerned
with the crest factor of the waveform as it hits the PA.  This will be the
same as the crest factor of the waveform we put in the audio input if crest
factor is invariant under frequency shift.  Is it?  I haven't found a
theoretical argument one way or the other, but here are some calculations...

                       peak    rms
S(1) + S(2) + S(3)     2.50   1.225
S(2) + S(3) + S(4)     2.75   1.225
S(5) + S(6) + S(7)     2.95   1.225

where, S(f) = Sin(2pi*f*t), t in the interval [0,1].  So, S(1)+S(2)+S(3)
would appear to change its crest factor when frequency shifted.  Check out my
calculations here; i could be fouled up.  If crest factor is not invariant
under frequency shift, then i'm not sure we know how to generate audio
waveforms that will produce a low crest factor at the xmit PA.


#: 73852 S17/TAPR NNC/DSP
    14-Apr-88  20:35:45
Sb: #73841-#Crest Factor Invariance?
Fm: Tom Clark W3IWI 71260,3640
To: Franklin Antonio, N6NKF 76337,1365 (X)

Franklin -- is the SSB xmtr has no filter distortion and all stages
are perfectly linear, then the relative amplitudes and phases of
all baseband components map directly to RF. Just think of each tone
as a phasor, spinning merrily. All the perfect SSB xmtr does is to
spin all tones faster by the same amount.
If the SSB receiver is perfectly on frequency but has no way to re-
construct the phase of the xmtr's oscillator, then it de-spins them
but adds a constant phase shift to all components (the unknown phase
difference between the LOs).
It is only when the perfect filter (including the ionosphere as a
dispersive filter whose properties can, at best, be only known in
a statistical sense) and the perfect amplifier hypothesis breaks
down that we get into trouble.


#: 73867 S17/TAPR NNC/DSP
    15-Apr-88  04:20:26
Sb: #73852-Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640 (X)

I agree with your statement.  Pls reread my original msg. The SSB xmtr
frequency shifts the input signal.  If crest factor is not invariant under
frequency shift, then the crest factor of the signal at the PA (where we are
voltage limited) will not be the same as the crest factor of the input audio
signal.  That's all i was saying.

We also need to examine the magnitude of phase shifts within the SSB rig,
(which are essentially all in the crystal filters).  Sadly, many rigs have two
crystal filters, and use both of them on both xmit and rcv. But before we get
into details like phase shifts, we oughta make sure we're understanding the
effect of the frequency shift, which is more fundamental.

I think you misunderstood my original mail.  Sounds like you interpreted my
concern as being the 2nd order effect from mistuning of the rcvr, or something
like that.  No.  When i say frequency shift, i'm talking about the fundamental
SSB mixing operation going on in the transmitter, ie in at 1kHz, out at 7MHz.


#: 73900 S17/TAPR NNC/DSP
    15-Apr-88  14:00:24
Sb: #73841-#Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Good point!  The crest factor is definitely NOT invariant under a frequency
shift.  If we have a baseband signal s(t) and apply it to an SSB modulator to
shift it to RF, the envelope of the new signal becomes:

         2          2  0.5
{  [s(t)]  +  [h(t)]  }

where h(t) is the Hilbert transform of s(t).  The only signal whose envelope
is invariant under this transformation is a single sine wave.  Whether the
crest factor of a given signal is greatly altered by the transformation
depends entirely on how well-behaved its Hilbert transform is.  For instance,
the Hilbert transform of a square wave has infinite peaks, so you can get a
really nasty peaky RF waveform if you feed one into an SSB transmitter.
Fortunately, the Hilbert transform of most signals of interest does not blow
up like this, and I think the effect of SSB modulation on the crest factor of
signals like voice or multitone FSK is quite small.

I just read Tom's reply to you, and I think he is skating on thin ice.
Conventional mixing produces a DSB signal which preserves the envelope of the
baseband signal, but SSB modulation does not.


#: 73915 S17/TAPR NNC/DSP
    15-Apr-88  21:47:59
Sb: #73900-#Crest Factor Invariance?
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

It looks to me that the 'thin ice' is only that the DC component
of the baseband signal is indeterminate in the SSBSC case.
.
Franklin's point on filters is well taken. In past years I spent
a lot of effort characterizing the filters (many are ceramic) in
various radios for our satellite links. I found that the stock
filters used in FT726's were very bad both for 1200 baud FSK and
400 baud Manchester (equivalent to 800 baud biphase) PSK. PSK was
even more twichy with the 1200 baud modems.
FT726s with the cheap Jap ceramic filters would work at 1200 baud
only on LSB, but not on upper, due to the combination of filter and
radio (audio) passband problems. The PSK data had to be centered
at 1500-1600 Hz.
Took a look at Kenwood and was very impressed with TS711/811 for
VHF and TS940 on HF (that's why I bought them). The 711/811 have
a bit more amplitude slope with frequency than I'd like but the group
delay performance seems pretty good. Never tried ICOMs after the
IC720 which was also quite good.
In general my impression is that the filters in most modern radios
are pretty good. Make sure that the modulation spectrum only fills
about the central 80% of the passband, since the multi-pole filters
give horrendous delay distortion as you get near the filter skirts.
.
Franklin -- never saw a reply on mouses -- does your interface assume
stock Microsoft mouse?


#: 73928 S17/TAPR NNC/DSP
    16-Apr-88  01:48:28
Sb: #73915-Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640 (X)

Thank you for the summary of your SSB rig filter results.  I had been meaning
to ask you for same, but you beat me to it.

Re mouse interface in my spectrum analyzer pgm.. I assume the presence of a
mouse driver for whatever mouse you have.  I make mouse driver calls that are
compatible with both the microsoft mouse driver and the mouse systems corp
mouse driver.  (and have tested with both)  I assume that most clone mice come
with compatible drivers, and therefore should work.

Re filters again... how many poles in typical SSB rig IF filter?  maybe 6?


#: 74049 S17/TAPR NNC/DSP
    18-Apr-88  14:40:17
Sb: #73915-#Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640 (X)

Tom, I think we're talking apples and oranges here.  The SSB signal can
certainly be demodulated to yield an exact replica of the original baseband
signal (with the possible exception, as you say, of a DC component).  All I'm
saying is that the MODULATED SSB signal that you transmit will in general have
a different waveform and crest factor than the baseband signal.  If the SSB
waveform is ill-behaved, that makes it harder to transmit it faithfully such
that the baseband signal can be recovered at the demodulator.


#: 74056 S17/TAPR NNC/DSP
    18-Apr-88  16:33:37
Sb: #74049-#Crest Factor Invariance?
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

I don't understand this.  Let us suppose that the baseband modulation is (say)
300 Hz wide and I multiply it by a complex sinusoid (modulate in a fashion
that will allow me to derive SSB, these are completely equivalent). The
amplitude of the sum of the tones (even multiplied) is less than or equal to
the sum of the amplitudes by Pythagorean theorem.  The amplitude of the
individual tones is TOTALLY UNAFFECTED by the multiplication by the complex
sinusoid and the sum of the baseband waveforms is less than max over the sum
of the amplitudes of the individuals making it up.  Thus the crest factor
would be unaffected since it is this max.  What have I missed? If the 300Hz
were put in the center of the SSB radio filters and it were reasonably flat
etc etc is the reason for that at the beginning. Bob


#: 74065 S17/TAPR NNC/DSP
    18-Apr-88  20:55:03
Sb: #74056-#Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

I have worked out an explanation of the mathematics, and am preparing to type
up and upload same.  Crest factor is defn'tly affected by SSB modulation.
Darned hard to type this in plain ascii file without math symbols, etc.


#: 74109 S17/TAPR NNC/DSP
    19-Apr-88  16:54:10
Sb: #74065-Crest Factor Invariance?
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Please do since I am really confused.  You should have seen me trying to do
differential equations and multiple integrals in ascii before a meeting in
Boulder last year so that the Phase IV team could see my attitude control work
for the geo satellite.  Tom can attest to the fact that it was painful to say
the least. Bob




#: 74101 S17/TAPR NNC/DSP
    19-Apr-88  14:34:17
Sb: #74056-#Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366 (X)

The only incorrect statement you've made is "the crest factor would be
unaffected since it is this max".  The crest factor can be much less than the
sum of the max amplitudes of the individual sinusoids if you're clever about
how you choose their frequencies, amplitudes, and phases.  The problem is that
the SSB frequency shift messes up the relationship you've so carefully
constructed.

Consider what it takes to make a signal with a low crest factor like a square
wave: a series of odd-order harmonically-related sinusoids with just the right
amplitude and phase.  In other words, a bunch of phasors spinning merrily in
sync so that they never can gang up and create a big peak.  Now if we do a
frequency shift, we have destroyed the harmonic relationship.  The series
becomes divergent, and the phasors are free to run amok and mess up the crest
factor.

Barry


#: 74113 S17/TAPR NNC/DSP
    19-Apr-88  16:54:42
Sb: #74101-Crest Factor Invariance?
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

I agree that can be done so long as the frequencies are not rationally
related.  That is all that means.  They must have an irrational ONLY
relationship to fall below the max amplitude or else you are guaranteed that
the max amplitude will be achieved.  This is like beat notes achieving the sum
of the amplitudes only if the angular frequencies are rationally related. If
what I have said here is wrong, I am really confused. Bob




#: 73926 S17/TAPR NNC/DSP
    16-Apr-88  01:40:13
Sb: #73900-Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

Oh.  Of course!  Ok, now i'm calibrated again.  Now i remember why i've always
looked at this sort of thing using the complex signal model.  I will go back
to that way of thinking immediately.




#: 74012 S17/TAPR NNC/DSP
    17-Apr-88  20:53:28
Sb: 320C15NL chip
Fm: Tom Clark W3IWI 71260,3640
To: Lyle, WA7GXD

The sample chip arrived Saturday. Assuming it works OK, I'll pop
it into the board we will use for Dayton demo.


#: 74069 S17/TAPR NNC/DSP
    18-Apr-88  21:08:55
Sb: #RV-FFT's
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier 74615,1366 (X)

Found yet another article on Real-Valued FFTs that appears to be very similar
to the Sorensen et al paper.  "Improved Fourier and Hartley Transform
Algorithms application to Cyclic Convolution of Real Data" by Duhamel &
Vetterli, IEEE-ASSP Jun '87.  Interesting data:  The article claims they wrote
TMS32010 code that does 128-point real FFT in 572uS.  If i just multiply that
up to what one would expect for a 1024-pt xform taking into account only
required # arithmetic operations, i get 7mS!  Of course, 128 pts is small
enough to fit in internal memory, so one should multiply in another factor of
idunno what.  Vetterli is at Columbia U.  ([e-mail])  I sent
him mail asking for the sources.  He forwarded my request to Duhamel (who
works for a company called CNET in France somewhere).  He replied in the
negative. Apparently CNET considers it proprietary.  Well poo.  These guys
shouldn't be allowed to publish articles claiming discovery of new ("the
best") algorithms without publishing source code.  That's the only proof that
the algorithm is completely thought out!  I've read i dunno how many papers on
the new Number-Theoretic-Transform techniques for example... everybody claims
to have the next big hit algorithm, but none of them have thought it thru to
the point where they have even programmed it... and they expect me to?

Back to Vetterli & Duhamel.. Does it sound like their FFT runs faster than the
RVFFT you're writing?  If so, maybe it's worth a 2nd shot to see if they might
donate same.  I delegate this task to you.  You're much more agressive than I.


#: 74110 S17/TAPR NNC/DSP
    19-Apr-88  16:54:17
Sb: #74069-RV-FFT's
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Yes I found that one in the same journal you pointed out to me and have a copy
of it.  I am working on that code now.  Tom picked up your board a little
while ago and will be bringing it to Dayton.  See you there. Bob




#: 74111 S17/TAPR NNC/DSP
    19-Apr-88  16:54:27
Sb: #74069-RV-FFT's
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Sure I will go after them.  Etienne Pardoux, their boss, invited me to give a
talk there and at INRIA next spring.  Think I should include that in the price
of admission? I will definitely try and code that.  I was already going to do
all of them as I believe, as you do, that "the proof is in the pudding" or the
code as it were. Bob




#: 74080 S17/TAPR NNC/DSP
    19-Apr-88  06:24:49
Sb: Crest Factor ***!!!***
Fm: Franklin Antonio, N6NKF 76337,1365
To: ALL

I have just written a small writeup on my ideas re Peak-to-Average Ratio vs
Crest Factor, how these change under SSB modulation, etc etc. Was gonna be a
coupla pieces of mail, but it got out of hand.  It's now 13K long, so i'm
uploading it to DL17.

This comes complete with mathematical doodles to augment the astoundingly
clear and concise text.  I have inserted one small mathematical error to keep
you on your toes, so read carefully.


#: 74126 S17/TAPR NNC/DSP
    19-Apr-88  21:26:45
Sb: TMS320C25 development
Fm: Bob McGwier N4HY 74615,1366
To: ALL

I have to report a little "luck of the Irish."  I had to go to the UK as many
of you know and I couldn't attend ICASSP (Int. Conf. on Acoustics, Speech, and
Signal Pro.) in NYC.  I had tickets to several events that T.I. had put on
while there.  I gave them to my partner in crime at work, Maureen Quirk (hey,
with a Ph. D. in E.E. in DSP and Irish to boot how could we not be partners).
Dutifully putting these tickets in the proper place at the meeting, she won a
$5000 in TMS320C25 plug in card for the PC with all their development software
and other stuff.  She said, "I couldn't figure out how I would use it and
started to give it back but figuring that you would ring my neck if I gave it
back, I brought it home to see if you could use it."  I plugged it in today
and had a bit of fun to say the least.  It has an indefinite home ;-). Bob


#: 74145 S17/TAPR NNC/DSP
    20-Apr-88  12:46:27
Sb: #74109-#Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

CREST.TXT has been uploaded.  Have you grabbed a copy yet? I'd like to get
some consensus on this before i upload the next bombshell.


#: 74155 S17/TAPR NNC/DSP
    20-Apr-88  19:51:57
Sb: #74145-Crest Factor Invariance?
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

I have downloaded it but have not made it through it.  I am spending all free
time calculating moments of inertia and center of gravity for PACSAT for the
Ariane Espace which have to have them by next Friday and I leave for D.C. to
spend a couple of days with Tom and for work there on Monday so they have to
be done before the Dayton festivities start. Bob


#: 74173 S17/TAPR NNC/DSP
    21-Apr-88  06:36:24
Sb: #74145-Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Looks good to me, Ace.  Let's have the next installment!


#: 74172 S17/TAPR NNC/DSP
    21-Apr-88  06:36:04
Sb: #74113-Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366 (X)

Hmmm.  Just a problem of semantics, I guess.  I'm not sure whether we have any
disagreement here at all.  Anyway, onward!


#: 74152 S17/TAPR NNC/DSP
    20-Apr-88  19:45:53
Sb: Add one
Fm: Bob McGwier N4HY 74615,1366
To:  76703,407 (X)

Please add Fred Williamson, W1FWJ, 73337,3077 to section 17.  He was the
twelth person to get one of the Delanco Spry boards.  Courtney, if you are
reading this, Fred has not received the mailing that you made to at least some
of us. Bob


#: 74168 S17/TAPR NNC/DSP
    20-Apr-88  22:46:20
Sb: Schematics and Notes
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

I plotted the last sheet of schematics tonight.  Cris will pick them up, along
with a printed copy of my comments for them, tomorrow in the AM and should
have them mailed out sometime tomorrow as well, so you'll all hae something to
take with you to Dayton to keep you from neing bored... :-)

I will *try* to get time to upload a copy of the comments here as well before
I leave for Chicago, but can't promise I'll find the time.

Cheers,

Lyle

#: 74189 S17/TAPR NNC/DSP
    21-Apr-88  20:26:43
Sb: #74172-Crest Factor Invariance?
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

Right.  I sure am looking forward to Dayton, see you there! Bob


#: 74213 S17/TAPR NNC/DSP
    22-Apr-88  08:42:00
Sb: Mailing
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

I gave the four sheets of schematics to Cris this afternoon, along with nine
pages of notes.  She will get them duplicated and mailed out tomorrow, so we
slipped the schedule again...

Eric is getting his PC set up to do PC layout work.  When I get back from
Chicago, I will get the CAD package copy out to Tom so we can exchange board
layouts, schematics, etc., via CIS up/down load, or diskettes, or whatever.

If you think you are on the list for this information, and don't have your
copy by the end of next week, let Cris know at the office (not me!) and she
will verifyand get the stuff eroute to you.

Cheers -- and enjoy Dayton for me, I won't be back on here until then --

Lyle


#: 74259 S17/TAPR NNC/DSP
    23-Apr-88  18:16:43
Sb: #74173-Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651

I just finished the long awaited 2nd installment of the crest factor writeup.
This one includes results of computer search for optimum phases for (3,10)-ary
FSK.  Even reaches a conclusion.  File uploaded into DL17 as CRES2.TXT.


#: 74287 S17/TAPR NNC/DSP
    24-Apr-88  07:25:01
Sb: #74168-Schematics and Notes
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

Have a good trip. Bob

#: 74291 S17/TAPR NNC/DSP
    24-Apr-88  10:21:09
Sb: #74152-Add one
Fm: HamNet SysOp Scott W3VS 76703,407
To: Bob McGwier N4HY 74615,1366

Bob,

I'll add Fred to the Section 17 access roster right away.

Scott

#: 74405 S17/TAPR NNC/DSP
    26-Apr-88  11:14:29
Sb: #74259-#Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Thanks for your analysis.  I agree with your conclusion as far as n = 3 is
concerned.  To wax philosophical a bit, I think this all makes sense from an
information theory point of view.  We have a set of tones with a certain
number of degrees of freedom, in terms of amplitude, frequency, and phase. If
we use these degrees of freedom to the max in order to transmit information at
something approaching the channel capacity, we have nothing left over to
control the crest factor with.  On the other hand, if we minimize the crest
factor, we have little or no degrees of freedom left with which to send
information.  The only open question, I think, is whether some useful
engineering tradeoffs might exist between the two extremes for n >> 3.


#: 74446 S17/TAPR NNC/DSP
    26-Apr-88  21:41:40
Sb: #74405-Crest Factor Invariance?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651 (X)

Your philosophical argument is a bit hand-wavey.  ... but agrees with a
fundamental principle i hold dear... "conservation of difficulty". My
intuition at this point makes me believe that nothing will help you (including
n >> 3) if you want tones that are not evenly spaced. In general, a sum of
tones will always achieve the worst case peak except for the very very special
case where they are evenly spaced, or nearly so. Of course, that's just my
intuitive reaction to the results so far.  I can't prove it.

Doing computer optimization for n>>3 will be real hard unless we get some more
results from the math to help us.  Notice that all the computer optimized
phases came out to be pi * ratio of small integers.  If we could PROVE that
that would always happen, then the computer search could be MUCH faster.  If
you have any ideas along these lines, pls share 'em. My thoughts at this point
are to look to waveforms other than sums of sinusoids.

My pgm to optimize for n=3 was a quick & dirty.  Used floating-point math,
etc.  Probably would have to be redone from scratch to do anything useful
beyold maybe n=4.


#: 74458 S17/TAPR NNC/DSP
    27-Apr-88  06:26:48
Sb: HF Modem Stuff
Fm: Barry McLarnon VE3JF 71470,3651
To: DSP'ers

One of my colleagues recently returned from the IEE Conference on HF Radio
Systems and Techniques.  I just had a look through his copy of the
proceedings, and thought I'd relate a few tidbits.

High-speed adaptive serial modems continue to be a hot area for research,
stimulated by the interest in same in military circles.  As you'd expect,
these modems make heavy use of DSP techniques.  Just to give you the flavor of
what's involved in making one of these beasties run, consider the 2400 bps
design described by GEC/Marconi in the UK.  It uses a single QPSK signal with
a raw symbol rate of 1500 baud, of which 300 baud is used for adaptation of
the equalizer by inserting a 40-symbol training sequence into the data, 7.5
times/sec.  Processing power needed to implement the demodulator?  A cool 40
MIPS or so!  It uses a multiprocessor architecture and bit-slice technology.
They use 12-bit (yeah!) A/D conversion and 12 kHz sample rate in the modem
front end.

Coming back to reality... Harris Corp described their "automated link
establishment" HF data system, which uses 8-ary FSK and a symbol rate of 125
baud to achieve a throughput of 375 bps.  Four ms (2 ms at each end) of the 8
ms symbol period are discarded in the demodulator to protect against multipath
ISI.  The modem is implemented in a single (unspecified) DSP chip. They also
mention the use of Golay (24,12) error-correction coding, but no details are
given.  Golay seems to be the "in" code these days, as I saw it mentioned as
part of at least three different HF systems.

On a more ominous note, there were no fewer than 10 papers on HF radar.  The
authors were from 4 different countries (UK, France, Australia, China), so it
looks like lots of people want to get into the game with the two superpowers
currently engaging in this form of spectral pollution.

#: 74461 S17/TAPR NNC/DSP
    27-Apr-88  08:13:42
Sb: #74446-Crest Factor Invariance?
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Hand-waving arguments are my specialty!

I have no proofs either, but your intuition seems sound enough.  There seems
little doubt that the best cases are those with even spacing.  While this may
or may not prove to be useful, it is something to keep in mind when choosing a
set of waveforms for signalling.  Taking your example of (10,3)-ary FSK, for
instance, we could choose 64 of the 120 possibilities as our signal set, and
signal at 6 bits/baud.  On the other hand, 20 (or so) of the combinations have
evenly-spaced tones, so we could choose 16 of these and signal at 4 bits/baud.
So we can trade off bit rate (or bandwidth) to get improved crest factor. This
sort of tradeoff *might* be useful when we're talking about 300 bps modems,
but seems very doubtful at 1200 bps.

Here's another thought, just to muddy the waters a bit more:  How long does it
take for an ensemble of sinusoids with a particular set of starting phases to
reach their worst case peak?  Perhaps we should be trying to minimize the
crest factor of the waveform only over a finite duration, namely, one symbol
period.  We don't care what happens after that, since we will be starting a
new waveform at that point.  Does this additional constraint help at all?

BCNU@Dayton!


#: 74527 S17/TAPR NNC/DSP
    27-Apr-88  23:03:02
Sb: #74458-HF Modem Stuff
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651

Post the address and $$$ to get copy of the IEE HF conference proceedings.

#: 74694 S17/TAPR NNC/DSP
    02-May-88  18:15:06
Sb: #74458-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

I also attended this conference and have a copy of the proceedings.  I don't
volunteer to make a copy of the whole manual but I will make a copy of the
table of contents available to those who have been talking about the HF stuff.
I enjoyed the conference and as usual there was one or two good papers and the
rest were a re-hash with a new wrinkle or just a rehash altogether.  The
exception to this were the papers people gave on hardware implementations of
HF adaptive terminals.   DSP was a topic of many papers. Some official of the
RSGB and I had a race to jump up and shout at a person from France.  He was
talking about HF radar and about his monster transmitter and antenna.  He
boldly presented his frequency as 14.110 Mhz. We pointed out to him that this
was an exclusive amateur allocation in France and he just shrugged his
shoulders.  It is not only the Soviets doing woodpecker apparently ;-( Bob


#: 74695 S17/TAPR NNC/DSP
    02-May-88  18:15:16
Sb: #74527-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Institute of Electrical Engineers Savoy Place London WC2, UK I don't see "hide
nor hair" of a price anywhere. Fourth International Conference on HF Radio
Systems and Techniques.

Try to imagine an IEEE journal or proceedings with Jets, Ships, Helicopters
bombing a radar installation and featuring the bridge of a warship with a
multitude of HF antennas coming out here.  It was a decent conference. Bob




#: 74700 S17/TAPR NNC/DSP
    02-May-88  19:38:55
Sb: #Schematics
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Now that Dayton is over, let's get those comments coming!  I would like to put
the schematics to bed and get Eric cranking on laying out the prototypes
before I leave next week for Canada.

I have the pulse swallower from Mike Brock and will get it massaged into the
diagram of choice...

Lyle




#: 74706 S17/TAPR NNC/DSP
    02-May-88  21:21:39
Sb: #74700-Schematics
Fm: David Toth VE3GYQ 72255,152
To: Lyle Johnson, WA7GXD 76246,565

where in cAnAdA are you going, EH?


#: 74701 S17/TAPR NNC/DSP
    02-May-88  19:58:43
Sb: Schematics
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

CHucks comments have been uploaded to DL17 as CHUCK.DSP

Lyle


#: 74721 S17/TAPR NNC/DSP
    03-May-88  06:58:34
Sb: #74700-Schematics
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Lyle, the first thing I noticed was that no privision was made for changing
the anti-aliasing and conditioning filters.  What is adequate for an SSB rig
of course as you know, won't pass 9600 BPS data or CD output to be
interpolated and resampled for DAT ;-) ;-).  We need that put on a header, or
configurable in some other manner.  I think Dan is working on this isn't he?
Tell Dan also, that I will call him this week and sorry that I have been gone
for two weeks.  Eric gave me the message but my arrival for my twenty minute
talk and then return to DC didn't go as planned.  I will have other comments
later today. Bob

#: 74727 S17/TAPR NNC/DSP
    03-May-88  08:43:16
Sb: #74706-Schematics
Fm: Lyle Johnson, WA7GXD 76246,565
To: David Toth VE3GYQ 72255,152

Headed for Tumbler Ridge, B.C.  For you geography types, this is nearer
Chetwynd than Dawson Creek.  :-)

Lyle

#: 74732 S17/TAPR NNC/DSP
    03-May-88  11:59:55
Sb: #74721-#Schematics
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

I think this has been discussed before, but here goes again... If we claim
this thing will "do everything", and "it's only software", etc. (I, of course,
have never made such claims, but YOU have.) Then... the thing should be built
so that you can change from one application to another without removing
screws, opening box, moving jumpers, remembering that you've done so so that
you can remember to change 'em back before running that other application that
requires 'em back the other way, etc. So how come you're suggesting
antialiasing filter configured by a HEADER?


#: 74745 S17/TAPR NNC/DSP
    03-May-88  19:32:45
Sb: #74732-#Schematics
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Good question.  I don't care if we change it from the front panel, it just
seemed that the original suggestion we made (months ago) that all this be put
on a "game cartridge" got dropped by the wayside.  The "game cartridge"
approach was when the DSP card had no host and we wanted to get software to it
without a kludgy loader.  Then we thought better of not allowing folks to
implement a better mousetrap by not having a loader.  This lead almost
inevitably in my opinion to the general purpose microprocessor in place of
making it either IBM PC specific or limiting it to what could be done by
plugging it into a tnc-2.  When we got the GP host the only need for the "game
cartridge" was the filters and it just slid under the table. It is clear to me
that one set of filters is not sufficient.  I would be happy if we had filters
selectable with cutoffs that were okay for SSB radios, and then selectable
upwards.  It is not as if this is the first time we thought about it.  A
header is cheaper than a switch but your right about the lack of class in a
header. Bob



#: 74750 S17/TAPR NNC/DSP
    03-May-88  21:01:24
Sb: #74745-Schematics
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

One thought:  programmable lowpass filter ala Gould S3528.  Lyle will probably
disapprove of the price.  Last time i looked they were around $25., but i'm
not real sure of that number anymore.  (These are the chips in the SuperSCAF
in few months ago QST article.)


#: 74736 S17/TAPR NNC/DSP
    03-May-88  14:42:57
Sb: #74527-HF Modem Stuff
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

I can't find any info on the price, but I think they will accept orders that
are not prepaid.  Orders go to:

Institution of Electrical Engineers
P.O. Box 26, Hitchin, Herts.  SG5 1SA
United Kingdom

If you want to try phoning, the number is 0462 53331.  Tell 'em you want
Conference Publication No. 284.

Barry

PS: Nice meeting you at Dayton!  Maybe next time we can get organized a
little better.  BTW, the numbers I gave you re HF packet lengths were a
crock... way too long.  I was thinking in terms of bytes rather than bits
(Malibu racetracks aren't the best place to hold a technical discussion :-)

#: 74764 S17/TAPR NNC/DSP
    03-May-88  23:27:00
Sb: #74694-HF Modem Stuff
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

Re DSP board... one of the files said i should find the assembler
documentation in the pile of paper that shipped with the board.  All i got was
a board, hardware manual for the board, and pile of diskettes.  Is the
assembler doc somewhere among all those files?  or do you need to send me a
paper copy?


#: 74771 S17/TAPR NNC/DSP
    04-May-88  08:08:32
Sb: #74745-Schematics
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366

I am meeting with Dan and Eric tomorrow at lunchtime to get Dan's progress on
the filter issue.  I agree that we don't want something that has to be changed
by opening the cabinet.  The filters shown are admittedly sleazy; this is not
because I want to use sleazy filters, only that filters aren't my bag!

The problem with a "game port" is that we have to become mechanical engineers
and pay very close attention to "tempest shielding" which means more money.
Remember all the grief the computer manufacturers went through to get part 15
certification back in the early '80s to get the noise out. The Atari 400 and
800 are amazing in this regard, and the C-64 has 4800 bps diskettes as a
result!  We are talking about a big hole through which two high-speed
processors are trying to push digital noise!

As a minimum I would think we want filters useable in a voice bandwidth
application with the option to switch them out and use some sort of external
filter.  As a minimum.

Anyway, I'll report tomorrow on Dan's progress.  Meanwhile, what about the
shared DSP memory circuits, resolution of the DSP I/O address space vs. TBLW
usage, 2-channel analog MUX vs. dual analog I/O ports vs. single analog I/O
port, etc?  :-)

Lyle

#: 74814 S17/TAPR NNC/DSP
    04-May-88  23:51:25
Sb: #Dan and Lyle Mtg
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Dan came over tonight and the results of our discussions were:

1) We will look into using a SCF like an MF5 for anti-aliasing on the way in
and another on the way out of the AD7569.  Use the 8254 output to drive a
fixed divider as well as the MF5 (or section of MF10).  USe output of divider
to drive the AD7569.  This puts 3 dB point of filter at a fixed ratio to the
sampling frequency.  Make provision to bypass the whole thing in case someone
wants to.

2) Drop the memory swap scheme and look into a 16-bit wide FIFOed output port
from a cost perspective.

3) Give the TMS320 handshake latches for communications with the V40 like the
V40 has.

4) Use RIO5 (currently unused) to read a status register which would include
the handshake signals, etc.

5) Buffer the Centronics port or otherwise protect it from static, etc.

Lyle


#: 74871 S17/TAPR NNC/DSP
    05-May-88  19:22:13
Sb: #74814-Dan and Lyle Mtg
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

I REALLY like the thought of the centronics as a high speed (cheap) port to
the PC, but . . .  Most PC parallel are "one way" ports (see Phil's article on
the parallel interface for driving the ICOM radios by computer in the AMSAT
proceedings from Dallas for example).  I doubt those that are bidirectional
come standard so this would have to be added as an optional port. Bob




#: 74816 S17/TAPR NNC/DSP
    05-May-88  06:28:10
Sb: #74750-#Schematics
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Time flies!  The SuperSCAF article was actually about 2 years ago.  I know
because that's the length of time the one I breadboarded has been sitting
under the desk in my shack, waiting for me to package it up.

The idea of using the S3528 crossed my mind too, but I dismissed it since I
knew Lyle would have a fit about the cost.  Maybe it's not TOO bad though... I
just had a look at the catalog from a local retail clip shop, and the unit
price of the S3528 is listed at $11.59 CAN$, which is about $9.30 US$ or so. I
suspect that they could be had for $5 or so with a bit of finagling.  Lyle
will still have a fit, but it's worth looking into.

Also, it is a 7th-order elliptic, so the group delay could be a little much
for certain applications.  And it is certainly overkill for the D/A
reconstruction filter.  On the other hand, I HATE the thought of changing
headers when changing applications!


#: 74834 S17/TAPR NNC/DSP
    05-May-88  11:39:28
Sb: #74816-Schematics
Fm: Franklin Antonio, N6NKF 76337,1365
To: Barry McLarnon VE3JF 71470,3651

The IF crystal filters in most HF rigs are 8th order chebyshev already. Many
HF rigs have two of them in series, and use them both in the xmit chain and
recv chain.  So that makes 4 of 8th order chebyshev filters (all about the
same bandwidth) in series between xmit and rcv modems already.

I had no idea the S3528's were down to such a low price.  I've never seen them
listed in anybody's catalog.  I was planning to buy some from a local
distrubutor, who would, no doubt, try to charge me full price.  Re the catalog
you referred to... is this a place that's used to selling to amateurs in low
quantities?  If so, how about sharing nam,addr,ph#.


#: 74823 S17/TAPR NNC/DSP
    05-May-88  08:56:18
Sb: #74771-#Schematics
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

The following comments are kinda skimpy, but I haven't really had a chance to
take it all in yet.

Fully decoded I/O space: I'd like to see this stay, although its omission
would not be crippling.  Use of bottom 256 words of progmem for data is
convenient, for a couple reasons: (1) You can reserve a data area here from
the outset, and not bump into it unexpectedly later, as might occur if the
data was in higher memory. (2) The progmem pointer needed for TBLR and TBLW
can be loaded with a single LACK instruction.

Second analog port: the two-channel MUX is an acceptable alternative to a
second full-blown analog port, especially if it is a standard feature.

EPROM loader: I'm not sure if this is a good idea or not, but it does have
some appeal.  It depends on what proportion of the applications would run
standalone on the DSP board... most of the modems would probably fall into
this category.  If we go this route, then the DSP board must have direct
access to the LEDs [but I think it should have this in any case... this is
about the only area where I disagree with Chuck's comments.  Both the DSP
(DCD, tuning,...) and the V40 (CON, STA,...) would seem to need seem to need
access to about 4 LEDs or so].

Aside from the thumbwheel, I can see a need for a couple of front-panel
switches which can be read by the DSP chip.  This would allow the user to
manually control the MUX to switch between radio ports, or to control some
parameter in the application that's running (e.g., diversity on/off,
narrow/wide filtering, tuning indicator sensitivity, etc., etc.).  Yeah, I
know... there goes your 'clean' front panel, but having a few switches
available sure beats having to hook up your computer and download to the DSP
box every time you want to make some minor change.

Barry


#: 74869 S17/TAPR NNC/DSP
    05-May-88  19:21:48
Sb: #74823-Schematics
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

Ditto on the switches. Bob




#: 74868 S17/TAPR NNC/DSP
    05-May-88  19:21:28
Sb: #74771-Schematics
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

RIGHT.  I uploaded on all that earlier.  If we can just switch them out of
line, I will be happy.  Tell Dan I am spending 12 hours a day at work and will
be out of town all next week.  I will be glad when summer and the special
project starts out in California so that I can get away from the beck and call
of the folks jjjuuussttt far enough away that it is a pain in the butt to go
see them but too far for it to not waste 4-5 hours everytime I have to do it.

Bob




#: 74835 S17/TAPR NNC/DSP
    05-May-88  11:52:33
Sb: HF Modem Design
Fm: Franklin Antonio, N6NKF 76337,1365
To: ALL

For those of you interested in HF modem design, here's a 10 year old article
that helps you visualize the kinds of fading that can occur on HF channels.
The text of the article isn't very useful.. it's mostly about their
measurement technique, but the 12 pictures they call "Fadeograms" are great.
These are similar to sonograms used in speech analysis.  These guys xmitted a
multitone signal at one location, then rcvd at another location, putting the
audio output of an SSB rig into a sonogram machine.  Result is a picture where
horizontal axis is time, vertical axis is freqency, and gray scale is
amplitude.

The Fadeogram, A Sonogram-Like Display of the Time-Varying Frequency Response
of HF-SSB Radio Channels, by J.H.J Filter, et al.  June 1978, IEEE Trans. on
Communications, pp 913-917.


#: 74865 S17/TAPR NNC/DSP
    05-May-88  18:56:32
Sb: DSP comments
Fm: Bob McGwier N4HY 74615,1366
To: ALL

I have uploaded my comments along with those of Paul Newland, AD7I, hardware
father of the TNC-2.  He is still in their pushing for AMTOR as you will be
able to read but his comments are a different prespective and need to be
considered.  I have read Chucks comments and I like most of what I have read
with the exception of the LED question.  I would rather not have to figure out
a "status"protocol between the v40 and the TMS320C1X that says "go light up
the gobbly gook LED" when the entire operation of the LED is determined by
what the DSP chip sees.  This will enable us to have modem disconnects to
leave the DSP and still have LED readout on lock, DCD, level, etc.




#: 74870 S17/TAPR NNC/DSP
    05-May-88  19:22:01
Sb: #74764-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365

Didn't I tell you that I had the manuals for the assembler and the emulator
and would send them?  If not I boo boo'd.  I remember running around the last
minute trying to find you so that we could hand the board off and even though
I meant to tell you I might have forgotten.

Bob




#: 74872 S17/TAPR NNC/DSP
    05-May-88  19:26:08
Sb: DSP comments
Fm: Bob McGwier N4HY 74615,1366
To: Lyle

Forgot to comment on the second set of notes. I like the memory map. 128K
shared with the DSP and V40 seems adequate. Glad you thought about INTACK,
let's not have another PC-100 Agree on making the V40 generic Re:
interrupts/hardware, that is to say, don't assume TMS320C1X for the V40 board
design and the necessary extras on the DSP board. Thats all folks. Bob


#: 74890 S17/TAPR NNC/DSP
    05-May-88  22:12:00
Sb: #74870-HF Modem Stuff
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

You probably told me, and the importance of the matter didn't sink in. Now
that i've installed the board, ground down my BNC connectors, etc, it becomes
real obvious.


#: 74891 S17/TAPR NNC/DSP
    05-May-88  22:17:11
Sb: ProCad
Fm: Lyle Johnson, WA7GXD 76246,565
To: Tom Clark, W3IWI

Tom,

I gave the ProCad software and documentation to Cris this afternoon.  She will
be sending it to you via UPS brown label, I believe.  I set up an unlabelled,
unprotected disk so you can follow the normal install procedure and simply
ignore the error messages that arse.

Lyle


#: 74892 S17/TAPR NNC/DSP
    05-May-88  22:17:22
Sb: Filters an FIFOs
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

I am running a price check on the S3528P filter as well as getting a couple
samples.  Meanwhile, the MF10 can be set up to be a tracking filter along with
a divider chip for about $3.50 for a fourth order filter function.

Thinking in terms of "options", would it be reasonable to assume the second
analog port to be an option, and include provision for a second 8254 timer
chip and phase shifter to drive it?  Of course, parts wouldn't be included as
a "base" unit.

What if we drop the shareable memory and use a FIFO for buffering an output
stream, and make the FIFO an option as well.  It would only be used for TMS320
to TMS320 communication in most instances anyway (I think).  Anyhow, it would
cost about $20 to have 512 words of FIFO, so I think it would have to be an
option.

Comments?

Lyle

#: 74947 S17/TAPR NNC/DSP
    06-May-88  22:47:14
Sb: #74890-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365

Those BNC's are a real joke are they not?  He could have (and we all should)
replace them with the ones with the long neck but naaaaaa, that would be the
right way and it's more fun to curse and nash our teeth as you do an FFT and
see crap from the computer all over it. ;-)

Bob




#: 74949 S17/TAPR NNC/DSP
    06-May-88  22:56:16
Sb: #74892-Filters an FIFOs
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

I can't think of an application where I could use the FIFO to share between
processors in the DSP-1.  So long as it is an option, and the extra traces
don't cost $$$, go for it.  I don't think we need shared memory between
processors for the DSP-1 but we will for next generation.  O the modems we can
build with (say) two 56001 or two TMS320C25's.  WOW!

Bob




#: 74950 S17/TAPR NNC/DSP
    06-May-88  23:30:55
Sb: A new toy?????
Fm: John Conner WD0FHG 72165,743
To: ALL

Ok ... Since I have not seen any thing new since DSP4 I will just toss this
out and see if any one wants it.  I have a simple 2 channel scope program that
interfaces with the Dalanco board. It can record and view data files ( same as
format as FROM320.C ). Send the data to the 32010 for processing and display
both the input and output signals.  Run the debugger, the assembler, and your
small editor what ever it is.  Works on CGA and (better) EGA. And is full of
great examples of how not to write in C......

The ARC file is about 60K. If anyone is interested say so and I'll try to put
it where you can download it. It should be on winfree tomorrow.  Maybe Bdale
will have better luck trying to get this version to tomcat than the last time
we tried two weeks ago.

Winfree (Bdales UNIX sys) now has a 2400 baud slip link at [phone]. The
Gateway is 44.32.0.8, winfree is 44.32.0.1.

Next weekend is the Rocky Mountain Packetfest.  Andy wants me to say a few
words about DSP (and they will be few).  Just how much of what is going on
here is public?

john


#: 74983 S17/TAPR NNC/DSP
    07-May-88  17:27:20
Sb: #74949-#Filters an FIFOs
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366 (X)

Dan was thinking of an application where, say, DSP #1 did an FFT and got rid
of the data in a hurry to DSP #2 which did some complcated filtering or ??
algorithm on the FFT data, finally passing the results out to the V40.

Anyway, a couple square inches and a few traces should cost in the region of
dimes.

Lyle


#: 74995 S17/TAPR NNC/DSP
    07-May-88  18:16:59
Sb: #74983-Filters an FIFOs
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

I don't object to having the availability of this as an option.  If we don't
hurry up and get to camera ready copy I am afraid the cost of this thing is
gonna be $500.  Don't want that. Bob



#: 74984 S17/TAPR NNC/DSP
    07-May-88  17:27:27
Sb: #74950-A new toy?????
Fm: Lyle Johnson, WA7GXD 76246,565
To: John Conner WD0FHG 72165,743

John,

I tend to treat this stuff as discussions in the back room, not for public
dissemination, etc.  However, may primary concern in this regard is that we
don't tell folks specs (since the design is still being thrashed, much less
tested) dates (boy! has TPR gotten burnt on THAT!) and prices (we od course
will go over budget on this...).

Lyle

#: 75007 S17/TAPR NNC/DSP
    07-May-88  22:09:25
Sb: #74984-A new toy?????
Fm: John Conner WD0FHG 72165,743
To: Lyle Johnson, WA7GXD 76246,565

That is what I figured. Just wanted confirmation.  As for Crest factors ??? It
is almost understandable to me.  I'm sure I could find two others that might
also (Bdale and Bill Flyn or Jan King...he is talking on Pacsat).

John

#: 75019 S17/TAPR NNC/DSP
    08-May-88  12:44:52
Sb: #74947-HF Modem Stuff
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

The real problem is NOT the BNC connectors, but the fact that the board is
1/4" shorter than it's supposed to be.  If the board were the right length,
the BNC's would stick out the back correctly, and there'd be no problem.  I
suspect that the reason the board is 1/4" short is so that the BNC's don't
stick out the back the expected amount so that it is POSSIBLE to get the board
into a PC.  The combination of the BNC's sticking out and the board being full
length at the other end (ie end of board at front of computer is max length
from the connector) make the board almost impossible to insert.  I almost
replaced the BNCs with RCA jacks.  This would make it possible to insert, and
would allow the plate to be moved 1/4" farther away from the board, so ya
wouldn't have 't bend it.  Ah well.. water under the damn.


#: 75022 S17/TAPR NNC/DSP
    08-May-88  12:57:08
Sb: #74984-A new toy?????
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565

Gee... Tom and Bob did give out the specs at Dayton...  They said it would do
EVERYTHING.

#: 75043 S17/TAPR NNC/DSP
    08-May-88  22:15:40
Sb: #75022-#A new toy?????
Fm: Lyle Johnson, WA7GXD 76246,565
To: Franklin Antonio, N6NKF 76337,1365 (X)

Hmmm.

There we go misrepresenting ourselves again.  This one will do ALMOST
everything.  The next generation unit is the one that will do EVERYTHING!  :-)

Lyle


#: 75044 S17/TAPR NNC/DSP
    08-May-88  22:58:17
Sb: #75043-A new toy?????
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565

Thanks for clarification.  By the way, thanks for the hotel room.  Had you
been there, you would have enjoyed it.


#: 75052 S17/TAPR NNC/DSP
    09-May-88  11:50:09
Sb: Access Request
Fm: HamNet SysOp Scott W3VS 76703,407
To: DSP'ers

Bob/Tom et al,

Bob Nebel, K9BL, has requested access to this section.  Is it OK to add him?

Scott
#: 75185 S17/TAPR NNC/DSP
    11-May-88  13:27:02
Sb: #74834-Schematics
Fm: Barry McLarnon VE3JF 71470,3651
To: Franklin Antonio, N6NKF 76337,1365 (X)

Sorry for the delay in replying... been outta circulation for a few days. The
local place with the S3528's is Active Components, an over-the-counter
operation which is part of the Future Electronics distribution empire.  Their
prices are usually nothing to write home about, so I would be very surprised
if you could not find a considerably better price in your area.

Regarding your comments on all the high-order filters present in HF radios: I
didn't have HF applications in mind when I made the comment about the S3528's
Chebyshev response... I see no problem whatever in using them for HF stuff. It
would only be in higher-speed applications where the group delay could be a
problem.  It could be equalized in the DSP chip though.

#: 75295 S17/TAPR NNC/DSP
    13-May-88  03:05:18
Sb: #MAC320 ???
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier 74615,1366 (X)

Still waiting for the documentation.  Figured what the heck, and tried to run
it sans documentation tonite.  I typed the command "MAC320 xxxx.asm", and to
my utter surprise, it tries to read from my empty floppy drive A:. Is this
what's supposed to happen?  What am i missing?

Further Del-Spry question:  Interrupts.  Board can use INT2 or INT7.  These
are, of course, both used on my AT.  How do the rest of you get around this?
Do none of the extant programs use interrupts?


#: 75337 S17/TAPR NNC/DSP
    13-May-88  20:05:04
Sb: #75295-MAC320 ???
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Sorry.  I didn't get it off before I went off to DC for a week.  I am so far
behind on correspondence that it will take me a week to catch up.  Too much
traveling for the company.

If you have the source on drive C

mac320 source.cce

This looks for source.asm on the c drive and puts the hex on the c drive and
doesn't dump the entire listing.

I will mail it tommorrow.

Bob



#: 75300 S17/TAPR NNC/DSP
    13-May-88  08:18:04
Sb: #74871-#Dan and Lyle Mtg
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366 (X)

The standard PC Centronics interface IS bidirectional, even though not all of
the individual ports involved are.  For example, the first printer port uses
the I/O addresses 378, 379, and 37A.  The port at 378 is an 8-bit output,
which can't be changed without hacking the board (the output bits can be read
though).  The port at 379 is a 5-bit input, likewise unidirectional.  The port
at 37A is nominally a 4-bit output, but it can also be used as an input since
it can also be read, and the outputs are open-collector drivers.  To use it as
an input, you just have to turn the drivers on first.  There are a number of
software packages around which do bidirectional file transfers through the
PC's parallel ports.  I have one called File Shuttle, and it is remarkably
fast.  In benchmarks done by some of the PC mags a few months back, it was
significantly faster than the transfers done via the serial port at the max
rate of 115 kbs.  So a Centronics interface can come in very handy if you do
the appropriate cabling and programming.


#: 75338 S17/TAPR NNC/DSP
    13-May-88  20:05:11
Sb: #75300-Dan and Lyle Mtg
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

The original IBM, true blue 4.77 Mhz standard printer interface card was NOT
bidirectional.

Bob




#: 75348 S17/TAPR NNC/DSP
    13-May-88  21:03:42
Sb: #75300-Dan and Lyle Mtg
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651

Now that I read this more carefully, I see what you are talking about.  I am
encouraging the addition of the parallel port as an option.

Bob




#: 75335 S17/TAPR NNC/DSP
    13-May-88  20:04:47
Sb: #75019-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Hey, I have an idea, why don't we design our own DSP widget ;-). Bob




#: 75346 S17/TAPR NNC/DSP
    13-May-88  21:03:23
Sb: #75019-HF Modem Stuff
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

"water under the damn"  ?  I call that a Freudian slip.  I "damned" it a few
hundred times myself. Bob


#: 75357 S17/TAPR NNC/DSP
    13-May-88  23:21:50
Sb: #75295-MAC320 ???
Fm: John Conner WD0FHG 72165,743
To: Franklin Antonio, N6NKF 76337,1365 (X)

I'm not using any interrupts here to the PC ..... However my scope program
uses the interrupt from the PC to the 320.  This is jumper J4.  Have not seen
any one else using interrupts for anything yet.

John




#: 75362 S17/TAPR NNC/DSP
    13-May-88  23:27:32
Sb: #75337-MAC320 ???
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

what's the magic incantation to get a listing?


#: 75361 S17/TAPR NNC/DSP
    13-May-88  23:25:37
Sb: #75335-HF Modem Stuff
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366 (X)

Ouch!

Hey, it's coming guys, really...  I'll have the skiz in Eric's hands by Monday
for the DSP board.

Lyle


#: 75363 S17/TAPR NNC/DSP
    13-May-88  23:28:41
Sb: #75346-HF Modem Stuff
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Damn.  The "under" part was intentional.  The "damn" was a slip.


#: 75551 S17/TAPR NNC/DSP
    16-May-88  23:11:55
Sb: HArdware design
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

All,

I am using the TMS320C15 schematic  sent to you, with the following change:

1) Drop 74ALS679 and change PAL to a 20V8.  This makes all but the bottom 32
address locations in Program space available for TBLW operations, saves a chip
and a fair bit of power.

2) Add optional 82C54 timer chip to drive optional second analog port.

3) Add pulse swallower/stretcher to each timer.  This essentially alows Timer
2 to subsitute for 1 timeout of Timer 1 whenever commanded by the DSP chip, so
you can lengthen or shorten the timeout to adjust the phase.  The limit of
course is the 16 bit limit of the counter itself.

4) Add provision for optional FIFO (like IDT 7201) for high speed inter-DSP
communication.  This means traces only, no parts.

5) Drop memory swap capability.

6) Add 74HC74-style registers to tell the DSP chip when the V0 has read data
from the DSP chip or written ata to it.

7) Add readable latch for communications and other status read functions for
DSP chip.

Details will follow.  Lyle

#: 75646 S17/TAPR NNC/DSP
    18-May-88  21:35:50
Sb: #75551-HArdware design
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565

This looks super.  Please check telemail for my barf to PACLIST. Let me know
ASAP what you think about trying out ONG since he is really anxious to try it
out.

Bob




#: 75657 S17/TAPR NNC/DSP
    19-May-88  00:26:27
Sb: Schematic comments
Fm: Mike Brock WB6HHV 76246,546
To: DSPers

I just uploaded a bunch of comments on the 20 April 1988 schematics. Those of
you following the schematics might want to read them.
  Mike

#: 75818 S17/TAPR NNC/DSP
    22-May-88  13:39:36
Sb: #75300-Dan and Lyle Mtg
Fm: Phil Karn, KA9Q 73210,1526
To: Barry McLarnon VE3JF 71470,3651

Barry,

The typical PC parallel printer port can be easily modified to support
bidirectional operation.  I did that here to drive my Icom 271/471/751

computer control busses.  I described the modification in the AMSAT
Dallas proceedings over a year ago.

It's easy because the output buffer is a 74LS374, a tri-state buffer
that has its output enable/ pin grounded.  All you do is lift this pin
and connect it to a conveniently spare output bit in the 74LS174 control
latch, which becomes the read/write direction control bit.  (You may
also have to wire the input of this latch to the appropriate data bus
line, it depends on the card).  Then you can read input data with the
data readback feature you mentioned.  Because of the polarity of the
output enable signal, the interface defaults to output mode after a
reset, so it should still work fine as a normal printer port.

The clone printer boards seem to use much the same circuit as IBM.

Phil

#: 75896 S17/TAPR NNC/DSP
    25-May-88  08:11:15
Sb: #75818-#Dan and Lyle Mtg
Fm: Barry McLarnon VE3JF 71470,3651
To: Phil Karn, KA9Q 73210,1526

Hi Phil,

Yes, I know about the simple mod that can make the output buffer
bidirectional.  I just wanted to point out that bidirectional operation is
possible using completely unmodified printer ports, albeit in a more limited
fashion.  The commercial file transfer program I mentioned appears to transfer
5 bits in parallel in each direction.

While I've got your ear, a question about your TCP/IP code: do you know if
anyone has been able to get it to compile with Microsoft C (V5.0 or 5.1)?

We have 5 stations running TCP/IP in the Ottawa area now, and will have the
DSY modems up on 220 later this year.  I also tried NET on the Ethernet at
work, and it works fine except that I couldn't find a termcap on our VAX
(running ULTRIX) which would work well with your TELNET implementation.  I've
heard that one solution to this problem is to use an extended ANSI screen
driver on the PC side that offers better VT100 emulation.  Any
recommendations?

 Barry


#: 75917 S17/TAPR NNC/DSP
    25-May-88  15:06:18
Sb: #75896-Dan and Lyle Mtg
Fm: David Toth VE3GYQ 72255,152
To: Barry McLarnon VE3JF 71470,3651

so when are you going to ask for tcp/ip addresses ??? I'm waiting!

Dave


#: 75897 S17/TAPR NNC/DSP
    25-May-88  08:12:03
Sb: TMS320 FFT Wanted
Fm: Barry McLarnon VE3JF 71470,3651
To: DSP'ers

Does anyone have TMS32010 source handy for a 32-point FFT?  If so, I'd
appreciate it if you could upload it here.


#: 76033 S17/TAPR NNC/DSP
    27-May-88  08:14:52
Sb: #75917-Dan and Lyle Mtg
Fm: Barry McLarnon VE3JF 71470,3651
To: David Toth VE3GYQ 72255,152

I asked VE3MDL to contact you about that, but I guess he hasn't yet.  We are
using the 44.210.0.XX block for IP addresses at the moment.  I believe the
"210" corresponds to a block in use in this area for a non-AMPR subnet, so it
wasn't chosen entirely at random.  How does that fit in with your addressing
scheme?

Barry


#: 76145 S17/TAPR NNC/DSP
    29-May-88  10:18:16
Sb: #76033-Dan and Lyle Mtg
Fm: David Toth VE3GYQ 72255,152
To: Barry McLarnon VE3JF 71470,3651

well, 44.x.x.x IS an AMPR subnet ... 44.135.x.x is Canada ...
I suspect that 44.210.x.x is another country !!!
I await someone sending me a note --- need:
Hostname (ex at.ve3jf.ampr), ax.25 callsign associated with that host, full
name address telephone #, where you can be reached on packet (ex. ve3mdl @
ve3jf) and if one has an ARPANET path or UUCP, throw it in too

73, Dave



#: 76172 S5/Amateur Satellites
    29-May-88  20:14:28
Sb: #76086-FUJI OPERATION
Fm: Bob McGwier N4HY 74615,1366
To: Jack Davis - WA4EJR 72356,441

Phil Karn and I have the DSP demodulator working for 400 BPS.  We are
primarily making it run for command and range.  It runs an absolute <RING>
around the AFDEM being used as the standard to date.  I was copying AO-10
telemetry off tape with eye patterns wide open when the old telemetry system
was not even finding the sync vectors.  I did the DSP and Phil has done the
command/display software.  Works nicely.  Got some clean up to do and then we
will try it all out on III C when it does up.  The same can be used for 400
BPS RUDAK.

Bob

#: 76186 S17/TAPR NNC/DSP
    30-May-88  08:15:15
Sb: #FFT
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob N4HY 74615,1366 (X)

Sorry... I do have that stuff, originally from the TI BBS.  That particular
program didn't register as a general N-point transform when I browsed through
them.  Still would be interested in more optimized 32-point transforms if you
come across any.  For N = 32, it is probably feasible to store the data in the
on-chip RAM.

Guess you're busier'n a one-armed paper hanger these days!  I unfortunately
find myself diverted more and more lately into non-ham activities - seems to
happen every year around this time...

Hope the launch goes well.

Barry


#: 76258 S17/TAPR NNC/DSP
    31-May-88  07:34:52
Sb: #76186-FFT
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Phil and I are having a BLAST (pun intended).  Glad you found it.  Yes there
is definitely a better mousetrap.  That one is not straight line and it is a
complex FFT (unless that is what you want anyway).

The launch has been put off two days by a concern about gas injectors to the
turbines on the first stage.  We will learn more today.

Bob


#: 76203 S17/TAPR NNC/DSP
    30-May-88  12:11:02
Sb: #76145-#Dan and Lyle Mtg
Fm: ANDY FREEBORN  N0CCZ 73177,1317
To: David Toth VE3GYQ 72255,152 (X)

Dave,
Brian Kantor posted the latest Coordinators List on 21 May. The highest
number shown is 44.150.x.x.x (Yugoslavia).

If you do not have this list, let me know and I will post it here.

Andy



#: 76318 S17/TAPR NNC/DSP
    01-Jun-88  07:21:50
Sb: #76203-#Dan and Lyle Mtg
Fm: David Toth VE3GYQ 72255,152
To: ANDY FREEBORN  N0CCZ 73177,1317 (X)

yes, gimme latest list ... I asked Brian to CC: me on UUCP re TCP/IP stuff,
but was after 21 May ... did you get my msg to you on winfree ???
Dave


#: 76376 S17/TAPR NNC/DSP
    02-Jun-88  06:05:04
Sb: #76318-#Dan and Lyle Mtg
Fm: ANDY FREEBORN  N0CCZ 73177,1317
To: David Toth VE3GYQ 72255,152 (X)

Dave,
Don't have any idea how this thread ended up on this topic!

Yes, got ur msg on winfree. Guess I shud have replied to confirm it works.

Will upload the IP Address Coordinator file here.
Will use "IPADDR.TXT" for the filespec.

Andy

All,
In case anyone else is interested this file is the Brian Kantor, WB6CYT
worldwide list of TCP/IP address coordinators.



#: 76402 S17/TAPR NNC/DSP
    02-Jun-88  13:21:04
Sb: #76376-Dan and Lyle Mtg
Fm: ANDY FREEBORN  N0CCZ 73177,1317
To: ANDY FREEBORN  N0CCZ 73177,1317 (X)

Dave,
I uploaded it on DL15.
Andy


#: 76572 S17/TAPR NNC/DSP
    07-Jun-88  07:41:18
Sb: #DSP on AO10
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Bob N4HY 74615,1366 (X)

Dear Bob, a few notes on my DSP work. I have modified your SPECT1K program by
addind: 1) Running average smoothing on every 16 bins 2) Circular window
detector out of 8 FFTs 3) Statistical decision and display for scattering out
of 4 bins. I tried the whole on Oscar 10 and I am able to detect my echos with
less than 100 mW uplink, with signal completely disappearing from my audio at
2-3 W uplink level, while being clearly out of the noise with 50+ W. I have
heard of a DSP4 disk, is it a dream or true ;-) Last question: do you plan to
work on PSK decoder for Phase 3C? (real soon now!) Best regards, Alberto I2KBD


#: 76575 S17/TAPR NNC/DSP
    07-Jun-88  08:28:32
Sb: #76572-DSP on AO10
Fm: Bob McGwier N4HY 74615,1366
To: Alberto E. Zagni I2KBD 71360,3467

The decoder for Phase III C 400 bps Biphase PSK is done.  We now have over' 8
diskettes of stuff.  Tom and I just do not have time to duplicate 360
diskettes for all the members of the team.  We are working out a way for the
TAPR office to send these diskettes out.  Don't feel left out, the other folks
over here are still awaiting these last four diskettes also; other than those
who have actually seen us at some place.  I hope this gets worked out soon.
Send a note to Tom and remind him also.

Bob

#: 76603 S17/TAPR NNC/DSP
    07-Jun-88  21:30:27
Sb: #76575-DSP on AO10
Fm: John Conner WD0FHG 72165,743
To: Bob McGwier N4HY 74615,1366 (X)

Bob

If you can get the disks to Colorado about the middle of next week, I'll get
the things copied ( or get Andy to ;-> ) and send them out.  Andy has my
CopyIIPC board and was going to use it to do the next NET release. He leaves
in the AM for a week and it would take that long to get the 360 disks
anyway.....

John


#: 76909 S17/TAPR NNC/DSP
    16-Jun-88  23:54:49
Sb: DSP HArdware Status
Fm: Lyle Johnson, WA7GXD 76246,565
To: All

The 320C15 section schematic appears to be done (!) and will go to Eric in the
next couple days.  It just has to be plotted.  Dan and Eric and I will get
together to figure out the best way to get the prototype board layout done in
such a way as to get it into the hands of software developers ASAP.  Some sort
of easy way to hang it on a PC bus will be looked at, minimum.

The A/D and D/A filters are based on the S3528 filters used in the superSCAF
filter from QST a couple years back.  The filters turned out to be CHEAP
($3.30 each) and save a lot of grief.  Yes, they will be programmable by the
DSP chip.  In fact, now that everything (filters, sample clock, etc.) is under
control of the DSP chip, the old idea of making it hang on a TNC without a V40
processor as a "better modem" becomes feasible.  This simply means, to me,
that the V40 part can be made better since it will be "optional" for certain
applications.  This also helps drive down the price of the basic unit if a
user elects to forego the V40 part.

I will post a list of features and etc. in a day or so.  Just wanted you all
to know that things are in fact alive and progressing here.  I am hoping that
Eric will be in layout before the end of next week.

The results of the AMSAT project will probably modify the V40 unit a bit, so
stay tuned...

Lyle


#: 77059 S17/TAPR NNC/DSP
    20-Jun-88  22:46:45
Sb: NKFSA 0.97 release
Fm: Franklin Antonio, N6NKF 76337,1365
To: ALL

I have just uploaded to LIB 17 the latest version (0.97) of my spectrum
analyzer program NKFSA.  This program computes real-time spectra of an input
signal, doing all computation in the PC.  Features are...

1.  Runs on any IBM PC/XT/AT/PS2 or clone with CGA/EGA/VGA & DOS or OS/2 2.
Requires NO coprocessors or DSP chips. 3.  Contains interface for Dalanco-Spry
Mdl 10 board. 4.  Hooks and instructions for user-written interface to any A/D
board. 5.  Supports color on EGA/VGA displays.  Colors user-settable. 6.
Supports mouse, if you have one. 7.  Online Help. 8.  Selectable windowing
(rectangular, Hamming, Blackman) 9.  Special input mode for short data sets
(ie FIR filter evaluation) 10. It even comes with documentation!



#: 77156 S17/TAPR NNC/DSP
    22-Jun-88  22:53:46
Sb: #77059-NKFSA 0.97 release
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

NICE JOB!

Bob

Function:
#: 77237 S17/TAPR NNC/DSP
    24-Jun-88  21:27:35
Sb: #77156-#NKFSA 0.97 release
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Does Tom read mail on tomcat.gsfc.nasa.gov?  I uploaded latest version (0.97)
of NKFSA to tomcat, and sent him mail asking him to delete prior version (0.90
i think).  Instead, latest version appears to have been deleted.  Never got
reply mail, so i don't know if he goofed, or if the new file i ftp'd got
garbled (as has happened several times before), or if..


#: 77328 S17/TAPR NNC/DSP
    27-Jun-88  01:31:04
Sb: #77237-#NKFSA 0.97 release
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

He knows.  He hasn't been there much.  He and I had a weekend working meeting
on the west coast.  He has been taking time off to finish the PACSAT receiver
and the module command/control board (personal days).  This means he hasn't
been at work where TOMCAT is located.  He does know that your latest ftp
didn't make it or something like that.

Bob


#: 77329 S17/TAPR NNC/DSP
    27-Jun-88  01:34:33
Sb: #77328-NKFSA 0.97 release
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366

ok.  Thanks.  I may try to ftp it again.


#: 77332 S17/TAPR NNC/DSP
    27-Jun-88  03:25:42
Sb: NKFSA 0.97 SW
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Franklin Antonio N6NKF 76337,1365

Dear Franklin, I downloaded your NKFSA 0.97 program that is great! On my PS/2
model 70 with color display is very nice. I also tried on my DSP system based
on 12 MHz AT with coprocessor, Dalanco/Spry board and EGA display to show
Oscar 13 PSK beacon:super ;-) Best 73 and many thanks from Italy Alberto I2KBD


#: 77333 S17/TAPR NNC/DSP
    27-Jun-88  03:36:41
Sb: EME DSP!
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Bob McGwier N4HY 74615,1366

Dear Bob, do you survive on holiday? (i'm in my office now...) Any news of
Tom, I left him a message more than a week ago, but he didn't read it. The
disks also seems to have been eaten by some black hole... FINALLY I GOT MY
ECHOS FROM THE MOON WITH SPECT_KBD SOFTWARE!!!! The last version of modified
SPECT1K now keys PTT thru parallel port for 2 seconds, than FFT for another 2
seconds for any echos, adding the resulting spectra and then FFT another 2
seconds to subtract any anwanted signal around. The peak from the moon, with
auto doppler adapting is clear. Conditions were 120W on 433.010 and 2 yagis. I
will send you the final version ASAP. Best 73, Alberto I2KBD


#: 77342 S17/TAPR NNC/DSP
    27-Jun-88  13:10:34
Sb: #77332-NKFSA 0.97 SW
Fm: Franklin Antonio, N6NKF 76337,1365
To: Alberto E. Zagni I2KBD 71360,3467 (X)

Thank you for the kind words.  We're all looking at the OSCAR 13 beacon
lately!




#: 77362 S17/TAPR NNC/DSP
    27-Jun-88  22:05:27
Sb: #77329-#NKFSA 0.97 release
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

My office mate (Lloyd Welch) told me that Viterbi was working at Qualcomm.
True?

Bob


#: 77395 S17/TAPR NNC/DSP
    28-Jun-88  12:37:32
Sb: #77362-#NKFSA 0.97 release
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Yes.  Andy Viterbi was one of the founders of LINKABIT in 1969.  I joined
LINKABIT in 1972.  LINKABIT was sold to M/A-COM in 1979.  Became M/A-COM
LINKABIT.  Name then changed to M/A-COM Telecommunications. Mid-1985, seven of
us left to form QUALCOMM.  About that time, what was LINKABIT was split into
three pieces.  The VideoCipher division was sold to General Instruments.  The
remaining commercial stuff was sold to Hughes, and became Hughes Network
Systems.  The remaining military stuff is now M/A-COM Government Systems.
QUALCOMM began with seven people in July '85.  Irwin Jacobs, Andy Viterbi,
Andy Cohen, Harvey White, Franklin Antonio, Klein Gilhousen, & Dee Coffman.
Now have approx 150 employees.


#: 77363 S17/TAPR NNC/DSP
    27-Jun-88  22:05:43
Sb: #77333-EME DSP!
Fm: Bob McGwier N4HY 74615,1366
To: Alberto E. Zagni I2KBD 71360,3467 (X)

Alberto:

I am sorry, I wish this were a holiday.  This is grinding work out here in
this last bastion of slave labor, sunny southern California ;-).  I will be
here on this project all summer.  Tom swears that the diskettes will be done
real soon now.   I wish I could help you.  I just don't even have all the
latest stuff.  I don't keep a copy of all that stuff on my hard disk and I
didn't bring any of my floppy collection with me.

GREAT on the spectrum analyzer.  It will soon be time for us to hang a neat
set of detection statistics on the bins and have a real QSO.

Bob


#: 78499 S17/TAPR NNC/DSP
    20-Jul-88  01:36:35
Sb: DalancoSpry RFI
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier 74615,1366

Bob, you mentioned that you initially had some RFI problems with the
Dalanco/Spry board.  You didn't mention what you did to fix 'em. I have
recently noticed that i can hear the D/S board at certain places on 2m and
10m, but only when it runs certain software.  I don't know what s going on
yet.  Any info on your RFI experiences with the D/S board appreciated.





#: 78531 S17/TAPR NNC/DSP
    20-Jul-88  23:30:39
Sb: #78499-DalancoSpry RFI
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365

Sure, I have NEVER completely removed them all.  First I did not allow the
grounds of the connectors to touch the computer since those grounds float. Do
you know Courtney Duncan?  He has reverse engineered schematics for us on
these.  The only other thing I did was to put toroidal cores everywhere and to
finally tempest . .  errrrr I mean EMI proof the CPU with conductive paint in
the inside and scrape the paint off the edges where the sliding top touches
the base, etc.  The usual tricks.  The worst problem for me is the harmonic of
the 320 CPU clock that occurs in the middle of the WX satellite band.  If I
remember anything else I have done, I will pass it along.  WE ARE NOT GOING TO
REPEAT THIS with the DSP-1.  Quietness is a must.

Bob



#: 78544 S17/TAPR NNC/DSP
    21-Jul-88  10:49:11
Sb: #78531-DalancoSpry RFI
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

I have torroids on absolutely everything here.  The case of my PC has
reasonable looking RF gasketing, (it's a real IBM-AT).  I've been thinking of
putting the Dalanco/Spry on an extender & probing around to find the source of
the noise.  When i run NKFSA, it is audible at certain places on 2m & 10m, and
looking at the audio output of the radio on a scope, it looks like a little
spike once per NKFSA cycle.  I wonder if this has anything to do with the fact
that i halt the TMS320 once per cycle to slurp out the sample buffer?  I
wonder also whether i have the energy to go after the problem!





#: 78783 (P) S17/TAPR NNC/DSP
    25-Jul-88  22:40:10
Sb: #NKFSA97.ARC
Fm: John Conner WD0FHG 72165,743
To: Franklin Antonio, N6NKF 76337,1365 (X)

Franklin:
  I really like your program.  Have not done much with it but play so far. I
need to go back and redo some of my DSPSCOPE program now!

  In the AAREAD.ME file you say that the MACPARK programs are in the
distribution.  I find them in neither the ARC here nor the ones we just got
from Tom for ditribution.  If you would like them included in the set of 12+
disks we (Andy N0CCZ and I) will be sending out this week let us know.  Put
them on CIS or any where that is accessable via ARPA or UUCP (give Bdale
something else to do. |-> )

John




#: 78793 (P) S17/TAPR NNC/DSP
    26-Jul-88  00:17:31
Sb: #78783-NKFSA97.ARC
Fm: Franklin Antonio, N6NKF 76337,1365
To: John Conner WD0FHG 72165,743

Thanks for the comments.  I never did get around to contacting McLellen or
Parks re permission to distribute their program MACPARK, so i left it out of
the distribution at the last minute.



#: 78785 S17/TAPR NNC/DSP
    25-Jul-88  22:40:32
Sb: New DSP Disks
Fm: John Conner WD0FHG 72165,743
To: ALL

Andy, N0CCZ, and I are preparing to ship a new set of DSP disks late this
week.  From a quick look they appear to contain all of the files on TOMCAT. If
you have any thing that you would like to include in this shipment please get
the files to me by midnight Wed.  You can put them on CIS, or somewhere
accessable via UUCP or ARPA, just tell me so I can get Bdale to go get them.
(TOMCAT is not a good place at the moment the connection from COS seems to
have diodes in it. )

John